Kako sem star WordPress 6.0 prilagodil novemu PHP 8.3, da je hitrejši, neodvisen in varen
Ko sem se lotil prenove svoje strani, nisem začel z najnovejšo WordPress različico, najnovejšo temo ali svežim “gurujevskim” seznamom pluginov.
Moja izhodiščna točka je bila precej bolj skromna: stara WordPress verzija, stara tema in strežnik, ki je že dolgo delal na modernem PHP.
Ni bilo idealno. Ni bilo priporočeno. Ni bilo “po pravilih”.
Ampak bilo je moje — in želel sem videti, ali lahko iz tega naredim nekaj hitrega, stabilnega in uporabnega.
Zakaj sem sploh poskusil?
Ker sem imel tri zelo preproste cilje:
- hitrejšo stran, brez čakanja
- stabilnost, brez skrivnih procesov
- manj odvisnosti od API klicev in zunanjih pluginov, ki bi mi diktirali, kaj se dogaja v ozadju
In ker sem imel že izkušnje s tem, kako WordPress deluje pod pokrovom, sem se odločil, da poskusim nekaj, kar večina ne bi: usposobiti star WordPress na modernem PHP in ga optimizirati ročno.
Kaj se zgodi, ko star WordPress zaženeš na modernem PHP
Težave pod nujno, ampak presenetljivo malo le teh.
Seveda — nekaj funkcij je bilo treba prilagoditi, nekaj datotek urediti, nekaj skript odstraniti.
Ampak jedro WordPressa je bolj robustno, kot se zdi na prvi pogled.
Največ težav ni bilo v sami združljivosti, ampak v tem, kar WordPress počne v ozadju:
- preverja posodobitve
- kliče WP.org
- zapisuje transiente
- preverja teme
- preverja plugin-e
- izvaja cron
- izvaja health-check
- preverja integrity datotek
In to počne tudi takrat, ko tega ne potrebuješ.
Kaj sem naredil drugače
Namesto da bi dodajal nove plugin-e, sem naredil ravno obratno:
- blokiral sem WP.org API
- blokiral sem update mehanizme
- blokiral sem cron
- odstranil sem nepotrebne skripte iz teme
- odstranil sem Google API klice
- odstranil sem TGM plugin zahteve
- odstranil sem companion plugin-e
- pustil sem samo admin-ajax, ker je nujen za Media Library in urejanje
In ja — imam vtičnike, veliko njih. Ampak svoje, ultra “lite”, brez API-jev, brez bloat-a, brez nepotrebnih funkcij.
Že rečeno, to ni bila “optimizacija po priročniku”.
To je bila optimizacija po zdravi pameti in osebnih izkušnjah.
Kaj se je zgodilo po optimizaciji
Rezultati so bili boljši, kot sem pričakoval.
Mobile
- Performance: 97
- Speed Index: 1.2 s
- LCP: 2.3 s
- SEO: 92
- Best Practices: 96
- Dostopnost: 81
Desktop
- Performance: 99
- Best Practices: 100
- SEO: 92
- Dostopnost: 77
To so številke, ki jih običajno vidim pri:
- statičnih HTML straneh
- headless WordPress projektih
- Next.js SSR rešitvah
- ultra lahkih custom temah
Ne pa pri stari WP verziji + stari temi + modernem PHP.
Sem se kaj naučil
Vedno se:
- WordPress ni počasen — počasne so stvari, ki jih dela v ozadju.
- Stara tema ni nujno slaba (to friziranje še pride) — slabe so skripte, ki jih vleče s sabo.
- Stara WP verzija ni nujno nevarna — nevarni so nepotrebni vstopni kanali.
- Plugin-i niso problem (tudi brezplačni lite vtičniki brez API-jev pridejo) — problem so plugin-i, ki kličejo API-je.
- Modern PHP ni ovira — ovira je WP, ki dela preveč stvari, ki jih ne potrebuješ.
In najpomembnejše:
ročna optimizacija je še vedno najboljša optimizacija.
Kam naprej
Po WP skripti pride dobra tema, kul no-API templates, brez googleapi fonts.
Če želiš tehnične podrobnosti, kode, .htaccess primere in razlago vsake blokade, bo naslednji članek šel globoko v tehnično ozadje.
Če pa te zanima, kako sem WordPress spravil na 1.2 sekunde brez “težkih” pluginov, bo drugi članek v seriji bolj teaser, bolj zgodba, manj koda.
WordPress 6.0.1 je namreč:
– zadnja verzija pred tem, ko je Gutenberg postal *invaziven*
– zadnja verzija, kjer je Classic Editor še deloval brez konfliktov
– zadnja verzija, kjer Jetpack ni bil “always‑on” in ni silil v module
– zadnja verzija, kjer WP jedro še ni imelo FSE (Full Site Editing)
– zadnja verzija, ki je še vedno “oldschool”, a že kompatibilna z modernim PHP
– zadnja verzija, ki je bila dovolj lahka, da si jo lahko optimiziral ročno
To je popoln most med:
– starim WordPressom (4.x–5.x)
– novim WordPressom (6.1+), kjer je vse blokovno, modularno, API‑heavy
In to je ključni del zgodbe, ker je verzija zadnja stabilna skripta med oldschool WordPressom in new‑way Gutenberg sistemom.
FAQ – Pogosta vprašanja
Zakaj sem izbral WordPress 6.0.1 kot osnovo?
Ker je WordPress 6.0.1 zadnja verzija, kjer Gutenberg in Jetpack še nista invazivna, Classic Editor deluje stabilno, FSE še ni obvezen, jedro pa je že kompatibilno z modernim PHP.
To je idealna verzija med *oldschool* in *new‑way* WordPressom.
Več o tem:
WP 6.0.1 kot osnova**
Zakaj WordPress dela počasi, čeprav imam hiter strežnik?
Ker WordPress jedro izvaja ozadne procese: WP.org klice, health‑check, cron, preverjanje posodobitev, preverjanje tem in pluginov.
To upočasni stran, tudi če je PHP hiter.
Več o tem:
WordPress ozadni procesi
Ali je stara WordPress verzija (6.0.1) varna?
Da — če zapreš nepotrebne vstopne točke, blokiraš WP.org klice, izklopiš update mehanizme in odstraniš skripte, ki jih ne potrebuješ.
Verzija 6.0.1 je stabilna in ne vsebuje FSE‑teže.
Podrobno:
Varnost stare WP verzije
Ali lahko WordPress 6.0.1 deluje na modernem PHP?
Da. WordPress 6.0.1 je presenetljivo kompatibilen z modernimi PHP verzijami, če odstraniš funkcije, ki niso več potrebne, in blokiraš procese, ki delajo nepotrebne klice.
Več:
WP na modernem PHP
Zakaj WordPress neprestano kliče WP.org?
Ker preverja posodobitve, teme, plugin-e, health‑check in integrity datotek. To upočasni stran in povzroča nepotrebne HTTP zahteve.
Tehnična razlaga:
Blokada WP.org
Kako izklopim WordPress cron?
Cron izvaja opravila, ki jih ne potrebuješ, če nimaš pluginov, ki zahtevajo urne procese.
Izklop crona zmanjša število PHP procesov in izboljša stabilnost.
Navodila:
**WP cron blokada**
Zakaj mora `admin-ajax.php` ostati dostopen, ali je možno da zaradi ajax ne dela wp galerija?
Ker WordPress galerija, media library in urejevalnik potrebujejo AJAX za nalaganje slik, galerij in modalnih oken. Ja, wordpressova galerija zmrzne, neskončno nalaga, če ga zapreš, WP ne deluje pravilno.
Podrobno:
Admin‑ajax razlaga
